From Java CoG Kit

• get in contact with Mike Russel
• see if CANARIE has made one too
• Integrate the code in the source forge archive
• create a downloadable jar file
• Integrate this in the to be developed configuation component
• prepare documentation for use and install

Contents 1 References 2 Dec 2001 3 some other note 4 gsi mindterm 5 Changes to cog for gsi term

References

• http://www.mud.de/se/jta/, The Java SSH source which is used in ASC Portal:

• http://www.mindbright.se/mindterm/

Dec 2001

Dear KDI developers/planers:

We have long being talking about how nice it would be to have a GSI SSH
available that could be started right within the Cactus Portal. I am not
sure if this has been done or is somewhere on the radar map. As not only
the Cactus group has asked for this I have thrown together a small
description of initial activities in order to peruse such an activity.
Before I continue to refine this (hopefully with your help) I like to
hear your input on this. As I can see NASA IPG seems to have a similar
requirement. As far as I can see the C version of the GSI SSH would not
fulfill the requirements posed by the Cactus portal. But I like to
verify this with you.

Thanks

Gregor

   
1         Java GSI SSH Shell Campaign

1.1      Background

   
   During the course of the last two years several developer contacted
   the Globus group for the availability of a GSI enabled SSH client that
   can be started out from a portal. These groups include the Cactus
   group and the NASA IPG group that provide the Launchpad. Having such a
   GSI SSH applet would allow portal developers to integrate a command
   line interface right into their portals.
   
1.2      Campaign Definition

   
   Develop a signed applet that provides a commandline interface that
   uses GSI for authentication. The applet canb be run either within a
   browser through applet technologies, or locally as application through
   the web start technology. In the course of the campaign it is to be
   evaluated if a JSP based version of this tool should also be
   developed. The actual implementation may be based on the plugin
   technology as used by several already existing Java terminal
   emulators.
   
1.3      Deliverables

   
    1. Preparation
       
    a. Analyze the available Java terminal emulators available on the Web
       (such as MindTerm, ...)
    b. Select an extendable terminal emulator from this set with suitable
       licence for plugin expansion or modification.
       
     Documentation
    a. Develop a UML diagram of the classes and methods
    b. Develop a detailed JavaDoc specification of the functionality of
       each class and method
    c. Provide a chapter about the GSI SSH shell and its use for the CoG
       Kit users manual.
    d. Update of the project progress.
    e. Evaluate the design/use of equivalent C tools in contrast it to
       possible different Java/OO design principles.
       
     Plugin Development:
    a. Develop a detailed implementation plan based on the chosen tool
       
     Usage
    a. Develop a test applet that includes the jar file as part of a
       simple portal (one page html file)
    b. Develop a shell script that can be run in the terminal emulator to
       demonstrate successive commands.
       
     Packaging
    a. Develop a packaging scheme based on ant that include compiling and
       signing
       
    1. Deliver a signed jar file
       
     Develop an ant file that can install the demo locally on a web
   server in the public_html directory.
   
     Develop the Java Webstart framework for downloading and installing
   the shell locally.
   
    
   
1.4      Funding

   TBD, Cactus?
   
1.5      Task List

   TBD, this requires the assignment of the deliverables to people with
   time estimates
   
1.6      Project Team

   TBD
   
1.7      Future Direction

   Integration in the Cactus Portal
   

some other note

Gregor,

Yes, I have included the code (as is, no documentation but GSI.txt has some info..) I developed prior to Jarek's implementation of the GSS-API in Java. I enhanced MindTerm to allow a user to authenticate to with GSI, However, this enhancment only applies where the user chooses which method to authenticate. Apparently, MindTerm implements authentication in several modules, instead of one. Thus, I have yet to add GSI to the separate SSH API also provided by MindTerm, which is used by jCVS apparently for running CVS over SSH.

One important note: I discovered and fixed a bug in the GSI-OpenSSH implementation by NCSA. This bug prevented one from authenticating to GSI-SSH without providing a username (seriously, that bug was not discovered before, very strange!). I will check to see if this fix has been applied to the source.

The main reason I did not meet my further development goals for GSI-SSH was because I was unable to install Globus on MacOSX and I did not have DSL at home to program. Now that I have solutions to both of these problems, I really intend to complete my other development goals for GSI-SSH with MindTerm, which include:

1) Augmenting the latest version of MindTerm. The version I have is slightly older. It's a very bad implementation by MindTerm because they implemented their own JCE package in a non-standard way and I had to find a way around that bad implementation! 2) Using Jarek's Java GSSAPI-GSI implementation and not my home grown solution (though, I learned about GSI in the process of developing it!). 3) Augmenting the underlying MindTerm SSH-API and making this available, with documentation, to any and all interested parties. This would include JavaCoG, GridSphere (the ASC and GridLab portal framework), GPDK (for GSI-SSH implementation of JobSubmissionBean), and jCVS (for a pure Java GSI-CVS client and server!). 4) Augmenting MindTerm to work with MyProxy. 5) Augmenting MindTerm so that it can retrieve proxies from a Grid portal.

I would like to create this project and release it under the Globus license. For simplicity, I would like to setup a repository here at GridLab, but in principle I don't mind setting it up at Globus as long as I have access to the CVSROOT for the project so that I can make changes as needed.

Will this do? Please, I'm very excited and interested in pursuing this with you, now that I can develop again!!! :)

Michael

gsi mindterm

Michael,

Cool. This is great news!

>> Recently, I was able to add a GSI user authentication mechanism to >> MindTerm, a popular Java terminal applet that implements SSH v1 and v2. >> I can make this source available to people immediately, but I have >> questions about how to make this enhancement generally avialable. I plan >> to communicate with the makers of MindTerm of course. My current work >> uses the IAIK libraries, in the same manner as JavaCoG. This may be a >> problem in conjunction with MindTerm, a commercial appplication which, >> according to its license, is free for non-commercial use and may also be >> modified for non-commercial applications. So, I will look into the >> non-IAIK implementation of the JSSE-like API now available in JavaCoG. >> Beyond this, how else should I see about making this available?

The new GSI API are not ready yet. So, I think the best route for now is to just to use JSSE API directly in your implementation. The delegation part should be fairly easy to reimplement/switch later (or you can just use Jason's code based on the free library) But once we are done with the new GSI API we can integrate it with your code.

>> Also, I'm wondering would it make sense to have a proper >> GSI-implementation of the GSSAPI before trying to work these >> enhancements into future MindTerm releases? How is that project coming >> along?

The proper implementation of the GSSAPI is nowhere at this point. I'm sure we will get to this at some point but we first need to find a good open-source SSL implementation. Anyway, for now I would assume that we don't have a proper GSSAPI implementation and work off that. That's our plan for the OGSA SOAP-level security project.

>> Furthermore, I'm looking into how I can enhance GSI-MindTerm so that it >> could work in conjunction with Web portals and scenarios where proxy >> certificates are not generated locally, but rather, retrieved from >> online certificate repositories, like MyProxy. In the case of the >> GridLab Portal, the project I'm working on now, we want users to have to >> logon only to the GridLab Portal and would like to be able to launch >> GSI-SSH shells on remote hosts without requiring the user to have proxy >> certificates generated locally, but instead to use the same certificates >> retrieved when they logged onto the portal. So, the main problem is how >> to enable the applet client to retrieve or use proxy certificates >> located the Web server. Ideas are welcome.

Have you looked into MyProxy anonymous GET operation? That might be helpful if I understand you correctly. With this you can retrieve users credentials over regular SSL connection (no client certificates needed) just with a password.

Jarek

Changes to cog for gsi term

Jarek: I'm adding some new GSI Socket API (org.globus.gsi) that will hopefully simply a lot of stuff and make the API cleaner. It especially should simplify writing server-side things like the gatekeeper or even some code for I needed for Tomcat (or maybe even the gridftp stuff). I also added gridmap file support to cog (to check if people are authenticated or not). The current server-side libraries were just not flexible enough to handle gridmap files...