0

I am tasked with creating SSO (single-sign on) for my company's application. I am straight out of college so am still fresh to the majority of the things at play here. I have done tons of research, I don't fully understand all of it but am doing my best. So the scenario I am in, I have a Windows Java Application(Swing) (NOT A WEB BASED APP), and a LINUX based server. Both have access to the same Active Directory(AD). I need to authenticate who the client is saying they are. I have attempted to use both Kerberos and WAFFLE to no avail. Kerberos has zero useful code examples or information online to even begin to try and use that form of authentication. WAFFLE I have set up but can't use because it requires a Windows server where mine is LINUX. What I am now trying to do is find out if there is some token that is stored in the AD that the server can authenticate against.

What I want to do is send the currently logged in Windows user along with a token to the server and the server to do a look up in the active directory to see if the username and token match. If they do then you are good to log in. Is this possible and does such a thing exist in the AD? Does a Kerberos token get stored in the AD? If so am I able to access such a token to send to the server to authenticate with? Does an SSPI token get stored there because that is what this WAFFLE code I have working seems to be using but I haven't been able to find how to query such a token in AD.

In the following code WAFFLE does some authentication using SSPI. I don't fully understand how it works but I wanted to see if I could send the token it is using here to the LINUX server to look up in the AD to check if it is valid but it doesn't seem to be something stored in the AD.

Any help is greatly appreciated.

private void negotiate() {
        IWindowsSecurityContext clientContext = WindowsSecurityContextImpl.getCurrent( "NTLM", "localhost" );
        String securityPackage = "Kerberos";
        int count = 0;

        // initialize a security context on the client
        clientContext = WindowsSecurityContextImpl.getCurrent( securityPackage, clientContext.getPrincipalName() );
        // create an auth provider and a security context for the client 
        // on the server
        WindowsAuthProviderImpl provider = new WindowsAuthProviderImpl();

        // now you would send the byte[] token to the server and the server will 
        // response with another byte[] token, which the client needs to answer again
        IWindowsSecurityContext serverContext = null;

        // Step 1: accept the token on the server and build a security context 
        // representing the client on the server
        byte[] tokenForTheServerOnTheClient = clientContext.getToken();
        serverContext = provider.acceptSecurityToken("server-connection", tokenForTheServerOnTheClient, securityPackage);

        do {    
            count++;
            // Step 2: If you have already build an initial security context for the client
            // on the server, send a token back to the client, which the client needs to 
            // accept and send back to the server again (a handshake)
            if (serverContext != null) {
                byte[] tokenForTheClientOnTheServer = serverContext.getToken();
                SecBufferDesc continueToken = new SecBufferDesc(Sspi.SECBUFFER_TOKEN, tokenForTheClientOnTheServer);
                clientContext.initialize(clientContext.getHandle(), continueToken, clientContext.getPrincipalName());
                System.out.println(tokenForTheClientOnTheServer);
            }  

            tokenForTheServerOnTheClient = clientContext.getToken();
            serverContext = provider.acceptSecurityToken("server-connection", tokenForTheServerOnTheClient, securityPackage);

        } while (clientContext.isContinue() && count < 5);

        if(count >= 5) {
            System.out.println("Unable to authenticate the user.");
        }else {
            // at the end of this handshake, we know on the server side who the
            // client is, only by exchanging byte[] arrays
            System.out.println(serverContext.getIdentity().getFqn());
        }

    }
  • The question in current state isn't much readable. I suggest, you edit & format this question properly for better readability. – Aaditya Sharma Aug 20 '19 at 15:27
  • How are you talking to the Linux server? Is it a web service? – Gabriel Luci Aug 20 '19 at 15:33
  • @AadityaSharma what exactly do you not understand? In general, I need to authenticate a client is truly who they say they are on the server. The client is a java based app(Not web app) and a Linux server. Both have access to the same Active Directory. Is there a token stored in active directory we can access for authentication? – Jeremiah Dixon Aug 20 '19 at 16:23
  • There is, but it will be difficult to build the entire authentication yourself. If the communication between your Java app and your Linux server is via HTTP, then there are ways to implement Windows Authentication to handle this for you. That's why I asked if you're running a web service on the Linux server. – Gabriel Luci Aug 20 '19 at 16:50
  • @GabrielLuci , so I am told that the connection between our Java app and Linux server is RMI over TCIP. If that helps make any more sense! – Jeremiah Dixon Aug 20 '19 at 16:58
  • I have no experience there, but I did find that you can use [JAAS with RMI](http://www.topsecurity.dk/cmview/View?id=1592), and you can use [Kerberos with JAAS](https://docs.oracle.com/javase/10/security/single-sign-using-kerberos-java1.htm). But that is all I know. – Gabriel Luci Aug 20 '19 at 17:11
  • @GabrielLuci Thank you! I will check both of those links out now. – Jeremiah Dixon Aug 20 '19 at 17:20
  • @GabrielLuci the JAAS with RMI requires a password and isn't a form of single sign-on. Kerberos also seems to require HTTP connection or a web based app, not a stand alone RMI connect application. – Jeremiah Dixon Aug 21 '19 at 17:43
  • _"Kerberos also seems to require HTTP"_ > where did you get that idea? Apache Hive supports Kerberos auth on Thrift RPC. And SPNego (the wrapper for Kerberos auth on HTTP) was introduced at least a decade after Kerberos was stable... – Samson Scharfrichter Aug 28 '19 at 08:24
  • _"the JAAS with RMI requires a password"_ > did you really try to modify the example config file, to insert a Kerberos auth section? Note that the same config file may contain multiple named sections, and each section may contain multiple protocols _(e.g. try Kerberos with keytab, failing that try Kerberos with default creds i.e. SSO, failing that try blah blah)_. That's why you always see `;` separators inside blocks and also after blocks. – Samson Scharfrichter Aug 28 '19 at 08:29
  • But note that this will not be simple copy-paste-for-dummies. Welcome to the magic world of Kerberos; prepare for hours of googling for arcane documentation and old mail threads, and weeks of debugging. – Samson Scharfrichter Aug 28 '19 at 08:31

0 Answers0