I apologize for starting a new thread on this topic, the other thread is archived:
http://www.jivesoftware.org/community/thread.jspa?threadID=14636
With all the talk about sasl lately, I’'m interested to know what the status is currently on this feature request.
Also, great work guys! Nice to see such an active team with such an intelligent business model.
Guess I’'ll just have to come to the Wednesday chat 8O
I’'ve been following this for a while, and it keeps getting pushed back. It was listed with a fix version of 2.5 most recently, but I see no reference to it in the 02/01 transcript. Now it appears to be bumped again to 2.5.1. Additionally, it is listed with a priority of “Major”, which would make it appear to be high on the priority list.
Has this been worked on? Is there an actual plan to fix it in an upcoming version, or am I wasting my time following a jm that is only passing from version to version in the plans with no activity?
I would like to see this implemented soon, and I’'d like to see spark support it as well - especially with the addition of the upcoming spark linux client.
Thanks!
Message was edited by:
AsTrONoT
AsTrONoT,
I would classify the feature as something we’‘d like to support. However, we have no Kerberos / NTLM expertise ourselves so don’‘t really know where to start. If we could find a community member that’'s dealt with coding this in Java before, that would be a huge help.
Regards,
Matt
Ive got plenty of Kerberos experience (and access to even more) but not much Java experience- any way I can help out?
Ive done a little bit of research into this, and I think GSS-API/Kerberos is possible. I started to write a simple java client/server that does gssapi auth in a pesudo xmpp stream, but was thwarted by the current java not supporting AES encryption. Ill have to get going on a realm that uses 3DES to get my tests hashed out.
Not having much Java experience, maybe someone can help me with this- in order to get java to do anything with Kerberos, I have to specify all sorts of commandline options and/or a config file. Is there a better way to do this? It seems kludgy to add -Djava.security.auth.login.config=gss.conf to the java commandline and have yet another config file to put things in.
Once I get a better handle on GSSAPI in SASL with Java, Ill take a look at the SASLAuthentication object and see how it might fit in there. It looks like that object has some hard-coded values of what possible sasl mechs so that another AuthProvider couldnt offer something else (like GSSAPI or KERBEROS_4, etc). It seems silly to make a change that organization without making AuthProviders supply a list of supprted mech types directly so that SASLAuthentication dosnt need to care directly. Any opinions on this?
I’‘d just like to take a second and say THANK YOU! for spending some time on this slushpuppie. It’‘s appreciated, and I’'ll be watching this thread closely.
copy & paste from JM issue:
Comment by Norman Rasmussen [/i]
I did some digging inside of Wildfire, and found that Java’'s javax.security.sasl.Sasl supports: CRAM-MD5, DIGEST-MD5 and GSSAPI.
So I figured I could hardwire Pandion to force GSSAPI (which wildfire accepts as a SASL mech), well doesn’'t seem to work - yet.
Wildfire gives me:
javax.security.sasl.SaslException: Failure to initialize security context Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)
Looking for ideas using google it seems that I’'ve missed a crucial step here somewhere.
I’'m running wildfire on win2k3 as user INTERNAL_SVC_Wildfire serving xmpp domain externaldomain.com.
I’'ve created a krb5.ini (copy & paste for working linux copy - that got rid of the first exception)
I used setspn to add both xmpp/externaldomain.com and xmpp/internal.server.local. (doesn’'t seem to help)
Lot of people seem to be using a jaas.conf, but I’‘m not sure what it should look like. (apparently newer versions of java don’‘t need it, not sure if 1.5.0 counts as new enough, requires a -D to set the path to the file, which I’'m not sure how to set for wildfire)
Of course, the whole operation is moot, because I think Padion only supports NTLM (and not Kerberos), but I could always try and implement the Kerberos stuff in python and/or Psi, or we can kick the Padion guys into enabling Kerberos too. Maybe the new version (mustang, aka java 1.6.0) of SASL will support SPNEGO and/or NTLM.
Comment by Norman Rasmussen [/i]
I’'ve managed to stick together a SASL-SSPI module for Win32 .
Contains full sources, for both SSPI ‘‘pass-through’’, and server-side implementations of PLAIN and EXTERNAL.
There’‘s no ‘‘licence’’ as such, but consider it GPL, with an exclusion for the jive team to release the code under it’'s dual-licence.
Doesn’‘t support wrap and unwrap, (not required for XMPP-SASL). Also hasn’‘t actually been tested with anything but the SASLCheck tool that comes with it. This includes the fact that I’‘ve not changed it against Pandion or xmpp.py, and I certainly haven’‘t installed the module on the wildfire box, and poked it to see if it works. (probably wouldn’'t because NTLM gives authid: ntdomain\user and it needs to be mapped to user@xmpp.domain)
See SASLCheck comments for how to handle passwords supplied by client via callbacks (eg: when mech is PLAIN) This would be most useful to make the XMPPCallback handler in wildfire implemented on the stream object directly. Then it could handle PLAIN and EXTERNAL directly, i.e. only with sasl framework.
http://www.darkskies.za.net/~norman/jabber/java-sasl-sspi.zip
Now:[/i]
(that url could be unstable over the next few days, as we’'re having power issues where that box is hosted)
I’‘ve done a minor fix in the sspi libs, fixes a JVM null pointer crash, but it requires some java class changes too. If I have some spare time this weekend I might look at getting wildfire building, and then I’‘ll try and patch the SASLAuthentication class in wildfire\src\java\org\jivesoftware\wildfire\net to support NTLM via my library properly. (’‘case AUTH’’ needs to send the initial response if it’'s supplied)
Of course, my library only works on a win32 environment, you probably find that the default java libs are fine for *nix. Also I expect my library to be replaced with native java code when Java 1.6 (mustang) is released - so I’'ve made it match the existing APIs as much as possible.
I have to specify all sorts of commandline options and/or a config file. Is there a better way to do this? It seems kludgy to add -Djava.security.auth.login.config=gss.conf to the java commandline and have yet another config file to put things in.
This is what brick-walled me. I couldn’‘t figure out where to put the -D options. So I’‘ve ‘‘given’’ up on using the Java GSSAPI mechanism, and I’'ll probably ‘‘override’’ it with the SSPI Kerberos mechanism.
It’‘s possible to get a list of supported SASL mechanisms. So a lot more of the getSASLMechanisms call could be relying on java’‘s sasl layer to make it dynamic. It’'s also possible to clutter up the list of mechanisms really fast this way too
I have to specify all sorts of commandline options
and/or a config file. Is there a better way to do
this? It seems kludgy to add
-Djava.security.auth.login.config=gss.conf to the
java commandline and have yet another config file to
put things in.
This is what brick-walled me. I couldn’'t figure out
where to put the -D options. So I’'ve ‘‘given’’ up on
using the Java GSSAPI mechanism, and I’'ll probably
‘‘override’’ it with the SSPI Kerberos mechanism.
I got this part working, the next hard part for me is getting Wildfire to understand the credential (GSS Token) passed to it. Im right now trying to work on a sample SASL-GSS client/server in Java, then when I get that going move it into Wildfire.
Note: I am using real Kerberos (an MIT flavor), and not Windows AD, so I dont know how things will pan out for Windows. I dont have access to Windows for development, nor the time/ability/desire to try. But my understanding is AD should have some of the generic Kerberos API availible, so GSSAPI should work.
It’'s possible to get a list of supported SASL
mechanisms. So a lot more of the getSASLMechanisms
call could be relying on java’'s sasl layer to make it
dynamic. It’'s also possible to clutter up the list
of mechanisms really fast this way too
Yes, but this is not a bad thing. SASL is a lot like what PAM is to Unix: A blessing and a headache. The current wildfire SASL code will need some good rewrite to support more generic SASL options. And since the UserProvider has a relationship with the SASL code, there would need to be some changes there too, but Im not even going to think about that until I have something that works.
Oh yeah, and a client that works too would be nice
… the next hard part for me is
getting Wildfire to understand the credential (GSS
Token) passed to it. Im right now trying to work on
a sample SASL-GSS client/server in Java, then when I
get that going move it into Wildfire.
In my java-sasl-sspi.zip is a small tester app, it basically simulates the raw sasl exchange. All that would be needed to xmpp’'ify it would be to base64 encode the data and add xml. It should serve as a very good starting point for trying to test any sasl mechanism.
since the UserProvider has a relationship with the
SASL code, there would need to be some changes there
too, but Im not even going to think about that until
I have something that works.
I doubt that very much. The only ‘‘UserProvider’’ interation would be to get the password for mechanisms that don’‘t support sending the password in plaintext to the server. This is currently working for DIGEST-MD5. Look in XMPPCallbackHandler for that peice of code. I’'m pretty sure that it would be a lot easier to have a reference to the SASLAuthentication and/or Session and/or SocketConnection objects inside XMPPCallbackHandler, because then the callback responses can be tailored for the specific auth mechanism.
Oh yeah, and a client that works too would be nice
I can’‘t think of a client that does GSSAPI, best option I can offer is my SASLCheck tester app. It’'s pure java (so is the server EXTERNAL and PLAIN mechanisms included). The only win32 specific part is the SSPI bridge.
I have put an updated copy of the framework on a more stable host : Index of /dl/sasl-sspi
v2 includes a ‘‘null pointer’’ exception fix (in the c code) that was causing the JVM to crash if the sspi auth failed.
since the UserProvider has a relationship with the
SASL code, there would need to be some changes
there
too, but Im not even going to think about that
until
I have something that works.
I doubt that very much. The only ‘‘UserProvider’’
interation would be to get the password for
mechanisms that don’'t support sending the password in
plaintext to the server. This is currently working
for DIGEST-MD5. Look in XMPPCallbackHandler for that
peice of code. I’'m pretty sure that it would be a
lot easier to have a reference to the
SASLAuthentication and/or Session and/or
SocketConnection objects inside XMPPCallbackHandler,
because then the callback responses can be tailored
for the specific auth mechanism.
What I meant was the different UserProvider instansiations may support multiple SASL methods themselves. For example, LDAP uses SASL, it could (should?) report back to the SASLAuthentication object which methods it supports and allow the SASLAuthentication object to “pass through” to it. While you can split the authentication completely from the identification, the two are so closely related it only makes sense for them to have ties together. But, you are right, there are many ways to go about this. If your LDAP implementation only supports PLAIN authentication, and you wish to use GSSAPI auth, then the SASLAuthentication object needs to know it can trust the GSS credentials and not use any authentication provided by LDAP.
Oh yeah, and a client that works too would be nice
I can’'t think of a client that does GSSAPI, best
option I can offer is my SASLCheck tester app. It’'s
pure java (so is the server EXTERNAL and PLAIN
mechanisms included). The only win32 specific part
is the SSPI bridge.
There are some patches out there to get Gaim using the Cyrus SASL libs, but Ive heard there are some incompatabilities between the JAVA GSSAPI and Cyrus GSSAPI implementations. Ive not gotten far enough to confirm this though. For the moment Im just going to test by hand.
I have put an updated copy of the framework on a more
stable host :
v2 includes a ‘‘null pointer’’ exception fix (in the c
code) that was causing the JVM to crash if the sspi
auth failed.
Ill take a look at it, maybe it will give me some insight.
What I meant was the different UserProvider instansiations may support multiple SASL methods themselves. For example, LDAP uses SASL, it could (should?) report back to the SASLAuthentication object which methods it supports and allow the SASLAuthentication object to “pass through” to it.
Ahh so in fact there’‘s zero ‘‘authentication’’ being done by wildfire, and in fact it’‘s sending the data received as something to log into ldap with? Won’'t it be an issue that the service name is ‘‘xmpp’’ and ldap expects ‘‘ldap’’? Some sspi mechanisms allow you to ‘‘delegate’’ permissions, formally allowing this to occur.
While you can split the authentication completely from the identification, the two are so closely related it only makes sense for them to have ties together. But, you are right, there are many ways to go about this. If your LDAP implementation only supports PLAIN authentication, and you wish to use GSSAPI auth, then the SASLAuthentication object needs to know it can trust the GSS credentials and not use any authentication provided by LDAP.
Yes, I think there needs to be some rework to say that some SASL mechanisms can do auth internally, and therefore the auth provider isn’'t required.
You are right, there would certainly be a problem as the principals would not match. It might be possible to do some delegation, but Ive not worked enough with that. But it did bring to mind the thought of authentication between wildfire and the user/auth/group providers. The wildfire server should be able to use SASL/GSSAPI to auth to the LDAP server so both the LDAP server and Wildfire know they can trust eachother. Otherwise, it is possible that one or the other had been compromised in some way (man-in-the-middle, etc). Proper SSL certs could do that too, but many organizations with well managed kerberos realms would rather leverage the existing infrastructure.
I think any rework in the auth code should keep in mind hybrid auth/user/group providers too. It would not be possible to manage a GSSAPI only server, as you could never log into the web interface that way. At the same time, it would be highly desireable to disable PLAIN auth on client (and even server!) xmpp connections, so some more fine tuned controls are needed. This sort of program planning is where I fall short from lack of experience as a programmer.
To me the goal in mind is getting SSO working for clients. Our corporate environment is winblows based, so using the SSPI modules (and NTLM) should be fine.
That being said I fully understand that wildfire needs to work just as tightly integrated in a full *nix / bsd GSSAPI infrastructure.
The holy grail is making sure that wildfire stays flexible enough to allow both ends of the stick with a single code base.