JAAS/NT hackable problem...

Question

Trying to develop a "fat client" to pass a Subject to the middle tier. Would somebody mind telling me how NTLoginModule is useful? Might be missing something obvious, but it is incredibly easy for somebody to re-write the pertinant "NT" classes to populate a Subject w/ false information. For instance, the NTUserPrincipal class has a method "getName()". I simply returned a bogus string, compiled, and added it to rt.jar and it worked - returned my bogus string instead of my login! Likewise, I was hoping that my server would come up w/ a "magic number" exception when the serialversionUID didn't match up, but alas, it's right there in the source, dammit.
This leaves me thinking a couple things: a) these classes are merely examples that should NOT be used. b) Sun really dropped the ball. c) I'm missing some kind of attribute that absolutely guarantees what the client sent over the wire is the class my server is expecting - ala the binary serialversionUID generated compile time.
To re-iterate, I'm trying to authenticate a user via "fat client" that passes the JAAS Subject to the middle tier.

Answer 1

Trying to develop a "fat client" to pass a Subject to
the middle tier. Would somebody mind telling me how
NTLoginModule is useful? Might be missing something
obvious, but it is incredibly easy for somebody to
re-write the pertinant "NT" classes to populate a
Subject w/ false information. For instance, the
NTUserPrincipal class has a method "getName()". I
simply returned a bogus string, compiled, and added it
to rt.jar and it worked - returned my bogus string
instead of my login! A similar concern, although more abstract, has been discussed on http://forum.java.sun.com/thread.jsp?forum=60&thread=519134
Actually, there is even an easier approach to fake a login that does not even require to change rt.jar - implement your own dummy login module that creates and adds a regular NTUserPrincipal to the Subject, and register this module instead of the NTLoginModule in the login config.
This leaves me thinking a couple things: a) these
classes are merely examples that should NOT be used.
b) Sun really dropped the ball. c) I'm missing some
kind of attribute that absolutely guarantees what the
client sent over the wire is the class my server is
expecting - ala the binary serialversionUID generated
compile time.JAAS is designed for login to a local client, and from its concepts seems to assume that key files (like rt.jar in your case, or the login config in my case) are protected accordingly, i.e. the app user does not have admin privilidges on his system. Like you, I was hoping for some way to be able to validate that the Subject and its associated Principals were created "correctly"...
To re-iterate, I'm trying to authenticate a user via
"fat client" that passes the JAAS Subject to the
middle tier.Had the same problem, and found two/three possible approaches, depending on your requirements:
- use a trusted third party that allows the middle tier to validate the subject, or validate that the client has correctly authenticated the user - the JRE currently provides Kerberos support, in my first approach, the middle-tier would have to use the user's ticket (passed from the client) and validate it with the KDC, the mostly cited approach is the combination of JAAS and J-GSS for Kerberos, which requires both the server/middle tier and the client (user) to authenticate against the KDC, and use their login contexts to establish a secure connection. This, however, does in both cases require a Kerberos deployment wtih a KDC, which may be a pretty hefty prerequiste for your application (AD implements Kerberos also)
- if you don't trust the client, then have it only do what it needs to do: obtaining the credentials from the user, and have the middle-tier do the critical part: authentication using the provided credentials. Linking this to JAAS: the client has the CallbackHandler that answers callback requests, the middle-tier has the actual LoginContext with its config file and authenticates using LoginModules. Since this involves a remote connection, you need to implement proxies for the LoginContext and the CallbackHandler, i.e. the client code does not create a LoginContext, but your LCProxy, and registers its CallbackHandler with the proxy - the LC proxy talks to its counterpart on the middle-tier, which creates the real LoginContext (which in turn loads the configured modules). The middle-tier part of the proxy needs to implement the CallbackHandler interface, such that it gets the callback requests from the modules and can pass them to the client-side of the proxy, which passes the callbacks to the real CallbackHandler of the client. The CallbackHandler answers the callbacks and sends them back via the proxy to the middle-tier proxy CallbackHandler, which passes them to the module, which authenticates the user, etc.
Note - with this approach, you pass the user's credentials over the net, thus you need to have this connection encrypted, e.g. through SSL!
Also, this approach obviously only works for modules that are callback based (LDAP, etc.), not for modules like the NTLoginModule, which just checks for the user that started the JVM, using some native Windows calls. If you need the latter, and following the approach of separating callback handling an authentication module, simply implement a special callback (e.g. OSUserCallback), and a basic login module that asks for this OSUserCallback; then you can configure on the middle-tier to use this module, and have the callback sent to the client - which, unfortunately, would have to implement a handler for your non-standard callback, but which is not a big burden.
Hope this helps, good luck!