Re: AW: [geclipse-dev] GSISSH

[Thomas Köckerbauer <tkoeck@xxxxxxxxxx>]

Hi

> [...]
>
> On the other hand if we manage to push your changes to the upstream author
> they will end up in the Orbit bundle used by Eclipse... :)
> We could write them an email (they welcome suggestions etc in
> jsch@xxxxxxxxxx) and ask.
>   How does/would your code connect to Globus? is it still possible to have
> your modified jsch plugin and use the other auth mechanisms even if you
> don't have any globus library around?

I terms of adding the functionality not many changes where necessary. I 
basically took the class for kerberos authentication and created one for GSI 
basing on that one (since both use the gssapi).

All other changes where necessary for getting that added to jsch. The next 
thing I had to change was the UserAuthGSSAPIwithMIC class that checks which 
OIDs (Object IDs i.e. which gssapi auth types) are supported by the server and 
the client and tries those which are supported by both. I had to change that 
class since all supported OIDs (only the kerberos in the original version) are 
listed in an array in there. And there is also a 2nd array which contains 
Strings (corresponding to the OIDs in the 1st array) that are used as a key to 
look the up the name (also a String) of the class implementing the specific 
gssapi authentication method in a hash map.
Then I changed the JSch class in which the hash map is filled (I added an 
entry there which defines the name of the class I added to be used for the gsi 
auth method) (This could also be done by some other class by calling the 
setConfig() method of the JSch class, but due to the org.eclipse.jsch plugin I 
have no direct access to the JSch class).

Adding that to the upstream version is somewhat difficult, the GSI specific 
class has a ton of dependencies (org.globus, eu.geclipse.core, 
eu.geclipse.core.reporting, eu.geclipse.globus, org.eclipse.core.runtime, 
maybe some others too). The other stuff is just there to add it to the list of 
available auth mechanisms.

Because of the dependencies I guess it is no option to put the GSI specific 
class into the jsch plugin.
The best way would be to somehow register the GSI specific class in the jsch 
plugin from another plugin outside, but this currently not possible for 
several reasons:
* The OIDs and the keys of the implementing classes for the hash map are
  listed directly in the GSSAPI class.
* Only the class names are in the hash map, and they are used to create
  instances (using reflection) i.e. the jsch plugin classloader is used for
  trying to create an instance, which will fail if the class is not in the
  same plugin


Cheers,
Thomas