A Web Server for Basic Grid Services

1
A Web Server for Basic Grid Services

• D. Calvet
• DAPNIA/SEI, CEA Saclay
• 91191 Gif-sur-Yvette Cedex

2
GRID and WWW

• Some basic GRID Services
• servers and users authentication
• users authorization
• secure data transfers
• remote process creation

• 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
• -gt the basis of the GRID can be seen as providing
  the  Execute  capability to the existing WWW

3
Providing Basic Services for Grid

• Dedicated packages, specific protocols
• E.g. Globus and gatekeeper protocol
• -gt 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 todays web server to
  provide the missing parts
• -gt 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)

4
Technical Choices

• An open-source JAVA based Web server
• portability, ease of customization,
• Choice JETTY (http//jetty.mortbay.org)
• Hook to host computer via CGI interface
• PERL scripts for interaction with host computer
• C programs to wrap critical parts, system
  commands
• -gt 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
• -gt Zero installation or specific program on the
  client side

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

• Server and Client authentication (JAVA)
• Supported by Jetty without any modification
• -gt but no check of CRLs in todays SUN JDK
  classes
• SUNs X509TrustManager replaced by our own
  version
• -gt support trusted Certs and CRLs a la
  Globus/OpenSSL

• Secure data transfer
• HTTPS support in Jetty and Web browsers without
  any change

• 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)
• -gt more refinements can be imagined

7
Implementation (cont)

• Users and accounts
• 1 account per user correspondence between the
  users DN and his local account provided by a
  mapfile
• Dynamic account creation on the server if a
  users 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

8
Demonstration
Top window server bottom window client
9
Demonstration
10
Demonstration
11
Demonstration
12
Tentative comparison with Globus
13
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

14
Summary

• Todays 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