Subject: Draft: Alternatives for Gateway Resent-Date: Sun, 16 Jan 2000 21:38:58 -0500 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Sun, 16 Jan 2000 21:11:14 -0500 From: "MARLON E.. PIERCE/ADMIN/WPASC/CONTR/SYRACUSE UNIVERSITY" To: gcf@npac.syr.edu Geoffrey-- This is a rough first take. Before getting into this, I must say that kerberized gateway is not really that far away. The plan we discussed at OSC (see http://www.osc.edu/~kenf/theGateway/gatewayYR2000.html ) was to break things in two and do parallel tests: OSC runs early user tests to check their design. I take a semiworking copy (PSE doesn't work but control applet does), get kerberized globus working, and have security evaluate everything. We then knit everything back together and deploy at ASC. We may not be able to make a May 12 deadline for this, but we might not exceed that by too much. General Concerns: NPAC will no longer exist after May. I do not know Tom Haupt's status with the Gateway project after May. Right now Tom is working closely with Ken Flurchik and Jan Labanowski on the PSE-WebFlow interface and will also be developing a client-side application program that will work around the Javascript problem. These will need to be completed before May in the event of Tom's departure from the project. Alternative 1: Focus efforts on delivering kerberized Gateway to ASC as soon as possible. Pro's: 1. Kerberized Gateway running at ASC has always been the goal, and it looks like we can deliver it. 2. Kerberos is likely to remain the preferred security method, even if/when PKI is implemented at ASC. Cons and risk factors: 1. Gateway is designed to bring distributed computing to ASC. This is done by using Java, CORBA, Globus, etc. The kerberized environment of ASC has forced a number of unforeseen compromises to be made. CORBA, for example, is designed to be a platform spanning specification for handling the communication between objects. This platform independence is only as good as the implementation that you can get from your CORBA vendor. The requirement for kerberized ORBs has limited us to one vendor (Adiron) and three platforms (Sun, Linux, WindowsNT). 2. It is possible that we have focused too much effort on using Netscape Navigator as the browser front end. The current version of NN, for example, has an inferior Virtual Machine that has forced us to use Sun's Java Plugin. But Javascript (also a Netscape product) does not work with the plugin. This unforeseen complication was discovered after SC99. Javascript is an essential part of the PSE-to-webflow communication in the current design. We have come up with a way to work around this, but this will require additional effort. It does not look like Netscape has any plans to correct this anytime soon. 3. ASC security has been consulted about design issues, but they will want to examine the entire working system. It is possible that they will require revisions. 4. Current plans call for Gateway to make use of Globus, and we have permission to install a kerberized version, but a working copy of this ultimately has to be approved by the security staff. 5. Effort devoted to early deployment of Gateway will subtract from current efforts in the redesign of the PSE-WebFlow interface. This redesign must be done before other CTAs can begin development. 6. A rushed deployment at ASC will not give the PSE team time to sufficiently evaluate their interface. This can result in a "black eye" for the project in the eyes of the users. 7. Gateway has not yet been used by many users at once. Unforeseen problems are likely. Alternative 2: "Take a breath and think about things" model. We have rushed the design and development of Gateway to meet deadlines for SC99 and now for May 12. This has led to a number of quick fixes needed to fit into ASC's special environment. Things to evaluate: 1. Should we drop Netscape Navigator as soon to be obsolete? 2. More generally, are we straying too far away from general trends in distributed computing and grid computing? 3. Are we forcing Gateway to be kerberized when the long term trend of the MSRCs may be towards PKI? If this alternative is choosen, Gateway would be developed and tested at another site, most likely OSC. This testbed would need to be funded. Pros: 1. Gateway development can focus efforts on redesigning the PSE-webflow interface so that other PSE developers can more quickly be brought into the project. 2. The PSE team will have sufficient time to have their work evaluated by friendly early users. Cons: 1. Not what was originally wanted by ASC PET. 2. What are the delivery conditions to ASC? Do we want PKI at ASC? Or do we just delay until we have thoroughly tested Gateway outside ASC to make sure it is a reliable product that people like? Alternative 3: Let ASC's Gateway make use of the PKI being developed by ARL. Gateway will be closely tied to PKI testing and evaluation at ASC. Pros: 1. Public keys and SSL are the security mechanisms of choice for most tools used by the internet and distributed computing. Web browsers use SSL for security. Globus security is primarily designed with SSL (although they use GSSAPI so you can crowbar in Kerberos if you want). Many ORB vendors provide SSL security. 2. Will be compatible with ARL's Gateway. Cons and risks: 1. I do not know if globus or Netscape will recognize certificates signed by the ARL Certificate Authority (and of course the Globus CA is not recognized by either of the major browsers.) 2. I have no idea how long it will take the ARL PKI to be approved by ASC, and there is always the possibilty that it will not. Marlon