Is there client-side Kerberos java.security.Provider implementation in WAFFLE?

[Baris Acar]

Does WAFFLE have a java.security.Provider implementation, or something that does a similar job?

Ideally I'm looking for something that could replace Quest SSO on the client side to allow my java client to authenticate the  with a web service that uses SPNEGO.

The following code works with quest - the first line configures Quest, I don't have any other config like jaas.conf etc:

public static void main(String[] args) throws IOException {

Security.insertProviderAt(new com.dstc.security.kerberos.winSSPI.WinSSPIProvider(), 5); // the java.security.Provider implementation.

URL url = new URL(args[0]);

HttpURLConnection connection = (HttpURLConnection)url.openConnection();

connection.setRequestMethod("GET");

connection.connect();

InputStream stream = connection.getInputStream();

List<String> s = IOUtils.readLines(stream);

for (String ss : s) {

System.out.println(ss);

}

}

This authenticates with the service at args[0], using Kerberos (which I can verify in Fiddler).

If no java.security.Provider in WAFFLE, is there anything which achieves a similar effect?

Alternatively is this something that would be considered in scope for WAFFLE at some point in the future?

Baris.

[Daniel Doubrovkine]

I don't think we have quite something like what you have above, but start at https://github.com/dblock/waffle/blob/master/Docs/faq/ClientSide.md. I'd like to be able to write ^^^ so I would say that's in scope.

--
You received this message because you are subscribed to the Google Groups "waffle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to waffle-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

dB. | Moscow - Geneva - Seattle - New York
code.dblock.org - @dblockdotorg - artsy.net - github/dblock

[Baris Acar]

Thanks.
I was going to raise an issue - but it might be this one:
https://github.com/dblock/waffle/issues/50

[Baris Acar]

Further to this: should I expect the WindowsLoginModule to be a drop-in replacement for the com.sun.security.auth.module.Krb5LoginModule (except with real SSO authentication without keytab/kinit/allowtgtsessionkey registry trickery)?

I initially assumed yes, but I suspect I have misunderstood what this loginmodule is actually for. Having tried it I get an exception. I'm running with:

com.sun.security.jgss.krb5.initiate {

  waffle.jaas.WindowsLoginModule sufficient debug=true;

};

With code:

        URL url = new URL(urlString);

HttpURLConnection connection = (HttpURLConnection)url.openConnection();

connection.setRequestMethod("GET");

connection.connect();

connection.getInputStream();

On Win 7 using 64-bit JDK8 I get:

java.lang.NullPointerException

at waffle.windows.auth.impl.WindowsAuthProviderImpl.logonUser(WindowsAuthProviderImpl.java:202)

at waffle.jaas.WindowsLoginModule.login(WindowsLoginModule.java:144)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:483)

at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)

at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)

at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)

at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)

at java.security.AccessController.doPrivileged(Native Method)

at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)

at javax.security.auth.login.LoginContext.login(LoginContext.java:587)

at sun.security.jgss.GSSUtil.login(GSSUtil.java:255)

at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)

at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335)

at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331)

at java.security.AccessController.doPrivileged(Native Method)

at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330)

at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)

at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)

at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)

at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)

at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)

at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)

at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:852)

at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317)

at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)

at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)

at sun.net.www.protocol.http.spnego.NegotiatorImpl.init(NegotiatorImpl.java:108)

at sun.net.www.protocol.http.spnego.NegotiatorImpl.<init>(NegotiatorImpl.java:117)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:408)

at sun.net.www.protocol.http.Negotiator.getNegotiator(Negotiator.java:63)

at sun.net.www.protocol.http.NegotiateAuthentication.isSupportedImpl(NegotiateAuthentication.java:130)

at sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:102)

at sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:180)

at sun.net.www.protocol.http.AuthenticationHeader.<init>(AuthenticationHeader.java:126)

at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1658)

at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439)

at com..........keytab_demo.App.main(App.java:62)

Based on fairly primitive understanding I think it ought to be possible to write a LoginModule that does do this - using WAFFLE's libraries, or perhaps simply using the JNA interactions for SSPI directly. I imagine that, as long as the Subject returned by the LoginModule contains appropriate javax.security.auth.kerberos.KerberosTicket private credentials, it ought to be possible to get it to work? Does that sound roughly sane or am I barking up the wrong tree?

Incidentally - I have had trouble stepping into WAFFLE 1.8.0 code from maven using eclipse - the point I step into often doesn't tend to match the call stack and stepping through jumps around non-sensically. It is possible that there is a mismatch between the .jar and the -sources.jar in mvn central? I don't have any such problems with WAFFLE 1.7.5.

Many thanks

Baris

[Matt Pangaro]

Hi Baris,

I know this was forever ago, but I was wondering if you had ever solve this. We have an existing JNLP-launched swing client app that currently depends on the ticket cache and Krb5LoginModule for its part of the Kerberos negotiation. As you've pointed out, the WindowsLoginModule doesn't appear to be a drop-in replacement, since it immediately calls the name/password callbacks. It does kerb negotiation with the credentials provided, but not using SSPI for SSO.

I've been hacking at it a bit, trying to get a ticket with Waffle to pass to our existing SPNEGO back end, but as you got, I just get the null pointer when trying to connect, since there's no TGT.

Anyway, it definitely seems like this ought to be possible, but all the docs and research I've done show examples for configuring a back end and/or some simple JAAS setup, and say "implement..." Did you get any further?

Thanks,

Matt P