Community
Participate
Working Groups
Enterprise environments often have security policies implemented through central user repositories (single sign-on through Kerberos and LDAP). Especially when SSH communication protocols is involved in our customer environments, Kerberos authentication needs to be supported. Our initial investigation shows JCraft SSH client can be configured to employ Kerberos authentication, but it's not entirely clear how that is possible through RSE subsystems. We would really appreciate if you can provide some insights into Kerberos authentication support RSE through config/calls, or if not currently possible, how feasible that would be in the next release. Given we are going through an important planning exercise, can you please let us know the ETA of the feasibility evaluation? (Ideally, we would need the answer in a few days, while hoping we're not the first to pose this question) Thanks very much for your time and support, Alex P
I'm interested in hearing hear how you think it can be done with JCraft JSch. Then perhaps I can get an idea what's missing for RSE. I don't have a Kerberos environment available though, so I don't think I can help anything with an actual implementation.
Initial and obviously superficial glimpse into JCraft in relation to Kerberos was triggered by those various links found through google, and then the API in the com.jcraft.jsch.jgss package: http://www.docjar.com/docs/api/com/jcraft/jsch/jgss/GSSContextKrb5.html I can only guess that JCraft has implemented the handling of the Key Distrib Center (KDC) handshake and authentication, but I don't have all the gory details figured out yet. Ideally, one would expect that the RSE would use the credentials to authenticate to the KDC server, and receive the Token Granting Token which would subsequently be reused to obtain generated tokens for subscribed services (target systems). That implies that there's a KDC hostname (different from the target system hostname) to be provided for the initial authentication, and then subsequent API calls would only take the target system's hostnames and generated tokens. From the RSE service API usage perspective, it only needs to allow for a new input param to flag when the credentials have to be used against KDC (rather than target system), while subsequent subsystem interaction would be carried using the tokens generated by KDC for each target system. I know it's a bit sketchy, but let's see if anyone else may have made previous inroads into this subject. Thanks, Alex
Before we can talk about Kerberos in RSE, we'll need to have it working with plain JSch. The "gssapi-with-mic" authentication method is in fact supported by JSch, but as far as I know this is a variant of Kerberos which is in use by Microsoft OS's so it might not make you happy in the general case. I suggest continuing the discussion about whether full Kerberos is possible with JSch or not on the JSch mailing list: https://lists.sourceforge.net/lists/listinfo/jsch-users Discussion there should help finding out if full Kerberos support is possible, what's needed to get it working, potential limitations, and perhaps some example code. Once we have some working example code (perhaps contributed by you under EPL on this bug), we can look at integrating this with RSE. Unfortunately few people have a full Kerberos installation available for testing, so Community help will most definitely be needed here. Given that we have RSE API Freeze with 3.1M6 in just 4 weeks, and feature freeze 6 weeks after, you'll need to be really quick if you want to see this in 3.1 / Galileo.
(In reply to comment #3) > Given that we have RSE API Freeze with 3.1M6 in just 4 weeks, and feature > freeze 6 weeks after, you'll need to be really quick if you want to see this in > 3.1 / Galileo. What is the next chance/release potential time frame if we miss 3.1 / Galileo ?
(In reply to comment #4) > What is the next chance/release potential time frame if we miss 3.1 / Galileo ? Well the important thing to understand here is that the project is Community driven. If there is a strong contribution from the Community, and strong request for a feature, and all parties agree that it's the best for the project, then there is a chance to do an extra release at any time. Our project is not like a few committers doing all the work and making all the plans, with consumers requesting the features and committers implementing them for free. Committers mostly do the work that's needed by their respective employers. But it's also in the interest of our employers that we help the community and contributors. That's why we solicit community input, and ask for contributions. That being said, another important aspect of any community-driven open and transparent project is that it's got transparent planning such that adopters can depend and rely on it. Our normal planning cycle is yearly, so the next feature release would be with the general Eclipse release train in June 2010. We cannot change that planning for every small request, but as I said there is a chance to do extra releases. Another technical aspect of this is, whether the new feature would require changes in the core framework or not, and whether these chances could be made in a backward compatible manner. If framework changes are not required, then the new feature can easily be developed and released as a separate add-on at any time. If framework changes are needed, it's harder though not impossible.
(In reply to comment #3) > OS's so it might not make you happy in the general case. I suggest continuing > the discussion about whether full Kerberos is possible with JSch or not on the > JSch mailing list: > > https://lists.sourceforge.net/lists/listinfo/jsch-users Martin, it may be my impression, but it doesn't seem like JCraft jsch community forums get much attention from the original author of the GSS-API support provided so far. I was hoping someone would have already provided some hint by now to my question posted on the subject: http://sourceforge.net/forum/forum.php?thread_id=3045396&forum_id=219651 http://sourceforge.net/forum/forum.php?thread_id=3045376&forum_id=219650 I hope it's just an impression and we might get some minimal input from the community.
I'm not sure how active the forum is. Please try posting to the mailing list instead. The JSch author and maintainer usually answers promptly.
FYI, in case you are interested in an Eclipse-integrated Terminal, this is possible with the upcoming TM 3.2 (Helios) release. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=314827 for details. At the moment, this only works for Terminals but not RSE (remote file) connections, but I would like to solicit opinions about the feature.
For what it is worth, allowing RSE to connect to a remote server via WinSCP would provide kerberos authentication. The absence of kerberos support limits our ability to use eclipse based IDEs. I would love to see it included in RSE.
I just posted the question again to the jsch-users mailing list, for a list archive (and potential responses) see http://sourceforge.net/mailarchive/forum.php?forum_name=jsch-users
Detailed instructions for using Kerberos with Eclipse / TM are here: http://sourceforge.net/mailarchive/message.php?msg_id=26939797 Looks like you'll need to install KFW from MIT, and setup a config file for JAAS to use it. I confirmed that the JSch version shipped with Eclipse does have the required file GSSContextKrb5.class . I'd like to get feedback from those actually using Kerberos, what we should do with this bug. Do you expect installation / configuration to be simplified? Since I'm not using Kerberos myself, I won't be able to help much but I can give guidance if any of you wants to contribute improvements to TM / RSE.
