Forum Stats

  • 3,780,922 Users
  • 2,254,456 Discussions


Cross Realm Authentication using NEGOTIATE protocol (SPNEGO)

843810 Member Posts: 46,938
edited Feb 28, 2010 1:42PM in Kerberos & Java GSS (JGSS)

I'm running JBoss that has:
1. NegotiateAuthenticator - converses with the browser via NEGOTIATE authentication protocol to obtain a GSSAPI Token (containing a Kerberos Service Ticket).
2. KerberosLoginModule - which uses Sun's GSSAPI implementation for Kerberos 5, to validate the Service Ticket.

Currently JBoss is registered as a service in our domain, and everything is working properly.

The problem arises when I wish to authenticate a user from another DOMAIN (on another Active Directory).

Does anyone have a clue on how to this?



  • 843810
    843810 Member Posts: 46,938
    Sorry, a bug.

    HTTP/SPNEGO in JDK doesn't realize the service belongs to another realm.
  • 843810
    843810 Member Posts: 46,938
    Can you please be a little more specific?
  • 843810
    843810 Member Posts: 46,938
    To start the negotiation, Java needs to generate a service principal name from the full qualified hostname of the web server. For example, if a client in domain X.COM wants to access, the service principal name for it should be something like http/[email protected] Unfortunately, currently Java mistakenly uses the name http/[email protected], where the realm name is still that of the client. The result is that if you access a web site in your own realm (domain), everything is OK, otherwise, fail.
  • 843810
    843810 Member Posts: 46,938
    But the process that creates the SPN for the web server (hostname) is the browser: IE or Firefox, not Java. code in the JDK, is used in my web server, to open the the Kerberos Service Ticket, and validate it.

    My question is basically: How do Internet Explorer builds the SPN for a given URL?
  • 843810
    843810 Member Posts: 46,938
    Oh sorry, I was talking about HHTP/SPNEGO on the client side.

    I have no idea how IE builds the SPN. I guess you can use a network sniffer (say, Wireshark) to inspect the Kerberos traffic between IE. KDC and your server. Pay attention to all the TGS-REQ packets, they should show what services tickets IE has acquired.
  • 843810
    843810 Member Posts: 46,938

    I'm really interested in your SSO solution with Kerberos and SPNEGO LoginModule. I'm currently working on a solution in order to use SSO beetwen a KDC and an existing JBoss J2EE Architecture. What I have understood for now :

    - We have to add a Service Account into KDC
    - We have to generate a KeyTab file (using ktpass) with the Service Account Credentials and put it on the application Server
    - We have to set a kind of NegotiateLoginModule on Jboss in order to handle the SPNEGO Protocol between JAAS mechanism and Internet. We have to configure the LoginModule for using the KeyTab file
    - We have to set a specific tomcat valve in order to put the correct Principal in each request (so as the silent login process is not done each time i suppose ?)

    Do you confirm that process ?

    I'd like to know more about the specific LoginModule that can be used ? Is it the NegotiateLoginModule from this wiki page : ?

    Have you customized the LoginModule code ?

    Can you discribe your solution ?

    It would be very nice of you, you would save my life ... and my brain to ... Sorry for my english 'cause i'm french :-)

    Best Regards,
  • 843810
    843810 Member Posts: 46,938
    Hi mAsaf,

    i'm writing a tool that does what u already have running.

    1. NegotiateAuthenticator - converses with the browser via NEGOTIATE authentication protocol to obtain a GSSAPI Token (containing a Kerberos Service Ticket).
    2. KerberosLoginModule - which uses Sun's GSSAPI implementation for Kerberos 5, to validate the Service Ticket.

    i want to implement this to a webapp that have embedded Tomcat running. Can u post some code examples on how to aquire the service ticket with the browser (NEGOTIATE authentication )?
    and how to validate it ?

    any help will be high regarded
  • 843810
    843810 Member Posts: 46,938
    Well, I haven't written most of it, but used a third party library that does most of the work:

    I've downloaded their library and wrote an Authenticator and a Login Module which simply uses them.

    Tell me if you need some guidance with that.

  • 843810
    843810 Member Posts: 46,938
    Thank Asaf for ur reply,

    i have a webapp that is written in Java 1.4 and should stay and have an embedded Tomcat running and use no web server only that embedded aplication server. I understand all pieces seperated and have a problem getting them together.

    My scenario should work as follow:
    A user use browser to acess the webapp and the browser should use SPNEGO to make the authentication between webapp & kerberos and the user. A configured Kerberos exists.

    So JGSSAPI talking the hole time about Client & Server implementaion. And i can't get around.
    - Where should i write the code that aquire the service ticket? Because my Client is a Browser (and the browser should do this - redirection or ?).
    - and where to write the one who unpack and validate it. (as a valve in the app server filter or a normal servlet binded to the webapp ?)
    - Is the unpack mechanism for the service ticket involved in SPNEGO or is it seperate?

    Is there then any Incompatibility of the Java versions because SPNEGO implementaion von sun exists only since Java 6.
  • 843810
    843810 Member Posts: 46,938
    edited Jun 19, 2008 2:19AM
    The user access a secured resource on your web application.
    You protect a resource in tomcat by including a <login-config> element in the web.xml and by specifying in the servlet mapping that certain resources are protected. The <login-config> has an element inside it, called <auth-method>. This is where you specify the authentication method you wish to use, when tomcat negotiates with the browser for credentials. Tomcat vanilla version comes prebundled with a few authenticators (which are java classes that implements authentication methods) as they required to by the Java Servlet Specifications (you can read it in Sun site):
    BASIC, FORM, DIGEST, and one more I forgot.
    So, in the web.xml, you will have:
    You want to use a different authentication mechanism, called Negotiate (by Microsoft), which is a limited implementation of SPNEGO. In order to support it, you need to write your own Authenticator class, which implements this method.
    After you write such class, you register it in tomcat ( I know how to do it if its an embedded tomcat inside JBoss): You add your class to the jboss-service.xml file in jboss/server/default/deploy/jbossweb-tomcat55.sar/META-INF directory.

    Lucky for you, some company released an open source project (Apache License i think) called TagLab which implements Negotiate protocol.
    All you have to do is, write a class that extends AuthenticatorBase (it's in tomcat's jars, needed only for compilation), which uses TagLab code.
    If you are using JBoss, then the story gets more complicated, since you need to move the actual authentication part of the authenticator into a JBoss login module.

    Regarding the ticketing flow:
    1. Browser access a secured resource in your web app.
    2. Your authenticator responds with a 401 response, and a special header:
    WWW-Authenticate: NEGOTIATE
    This tells the browser: We'll use the NEGOTIATE authentication protocol.
    3. The browser realizes it needs to acquire a service ticket.
    The service name is the url you've typed in (well, only part of it): http://fully-qualified-host-name
    It sends a request to the Active Directory, for a service ticket, to that service name.
    (that means you need to register your tomcat/jboss as a service in the AD, with that exact name)
    4. The browser tries to access the same resource url as before, this time, it adds a header to the HTTP request;
    WWW-authorization: NEGOTIATE encoded-spnego-token
    encoded-spnego-token is the SPNEGO token encoded in base64. The spnego token is basically a wrapper for the service ticket.
    5. The authenticator unwraps the spnego token, and aquires the service ticket. Using the secret key (shared only by tomcat and AD) it decodes the service ticket and makes sure the timestamp is close enough to the current time. Those two steps are the validation that this is the user that sent the ticket. If all passes, the user is valid to aquire the resource.
    6. The authenticator returns true, and passes control to the servlet container which sends back the requested resource. Otherwise, a 403 response is sent back to the browser.

    Feel free to ask some more questions, since I took me a month of digging through the net to make this work and understand all the flow.
    I should start writing a white paper on this.

    Edited by: mAsaf on Jun 19, 2008 9:04 AM
This discussion has been closed.