a web server for basic grid services d. calvet dapnia/sei, cea saclay 91191 gif-sur-yvette cedex
TRANSCRIPT
A Web Server for Basic Grid Services
D. Calvet
DAPNIA/SEI, CEA Saclay
91191 Gif-sur-Yvette Cedex
[email protected] 2 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
[email protected] 3 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)
[email protected] 4 Lyon 21 November 2001
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…-> 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
[email protected] 5 Lyon 21 November 2001
Software Architecture
CGI
GUI, Serverauthentication
Web server
HTML formPerl script
ExecvpUpload
User B
adduserSUID root
X.509 Certsand CRLs
Clientbrowser
X.509 Certs(and CRLs)
Environment variables
DN allowedDN denied
DN to login
HTTPS
User A
Dynamic account setup
User authorization
ExecvpUpload
Clientauthentication
Secure channel
Process creation
HTML (stdout)
(stdout)
[email protected] 6 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
[email protected] 7 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
[email protected] 12 Lyon 21 November 2001
Tentative comparison with Globus
Function Globus 1.1.3 Proposed scheme
Client software/interface Specific / command line Internet Explorer, Netscape / Graphical
Single sign-on Yes (grid-proxy) No
Server protocol Proprietary (gatekeeper) Web standards: SSL, HTML, CGI…
Data transfers Authenticated; plain-text only Anonymous and in plain-text (HTTP) or authenticated and encrypted (HTTPS)
Information service GIS, GIIS, LDAP browser Not studied – adapt web search tools?
Other services MPI support, GSI ftp, HBM Dynamic login setup
Platforms/OS support limited Clients: almost any; servers: UNIX-like
Critical part for security Daemon running as root Hooks to some SUID commands
Development effort 10’s of person-year 0.5 person-year
Deployment effort Administrator and user training Web server administration
[email protected] 13 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
[email protected] 14 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