In addition check this URL: http://code.dblock.org/single-sign-on-tomcat-negotiate-authenticator-kerberos-ntlm-w-waffle
This allows you to plug-in an authenticator that authenticates automatically for you and sets the remoteUser for java requests. Its pretty good.
When i put this into the VueServlet it works and i put a test.jsp file under it to demonstrate the authentication works.
the same applies to the DMS servlet!
However the VueServlet seems to make its own new request from VueServlet to DMSServlet to the remoteUser is the username of the windows service the application server is running as.
Note: All i want is the windows username of the person using AutoVue. Passing a username via the applet is not very good and i can use the built in JAAS authentication which is OK but we don't want to have the user inputting their username and password everytime they open their browser.
It seems to me that VueServlet should pass the remoteUser value in some way to the DMS servlet but it doesn't so even if you have your own authentication mechanism the VueServlet doesn't let the DMS servlet know any information about the original request to the new request.
I really need some help with this. How are you supposed to log into any DMS unless you pass credentials via the applet which is a security risk in itself because users can change the HTML code?
The behaviour you are describing is the expected one, it is the server that is talking to the DMSServlet, so it will be the account's credentials that will be forwarded is there is nothing else you do
The assumption that the VueServlet should pass the credential of the logged in user is unfortunately incorrect, it only tunnels requests from applet to server
There is an authentication mechanism that is part of the AutoVue deployment, there is no other way to pass credentials but that one
if you need automatic sign-in, on the applet side, you will need to have an authenticator in the applet
If you have a SSO solution, ie the VueServlet and the DMSServlet using the same security realm and authentication solution you can rely on the automatic signin build in the browser ie the page from the browser will authenticate, the connections from the applet to the server will have a security token (usually a cookie) and that can be used to automatically sign you in at the DMSServlet side
But essentially, without entering a user name and password or writing a module that will grab the WINDOWS credentials (which can only be securely done if you have NTLM) there is no work around.
Security serves a purpose, and in this particular case, you are trying to bypass it.
If i was to look at creating our own authenticator then how would this be passed back to the DMS servlet? All requests from the VueServlet take the identity of the windows service running the AutoVue service.
The applet and VueServlet is step 1 and once you are passed this and the person is authenticated it seems reasonable the DMS servlet would want to know who this person is to prevent passing sensitive data via the applet.
If the JAAS built into AutoVue is used then does this get passed back to the DMS servlet via the authentication section for each request made to the servlet?
Passing all cookie data back is handy but these cookies are bound to the client they came from a lot of the time and will not work from the DMS servlet (as this is seen as a different client)
I will ansewer item per item, so that we do not get confused
>>If i was to look at creating our own authenticator then how would this be passed back to the DMS servlet?
You ususually send information as cookies
>> All requests from the VueServlet take the identity of the windows service running the AutoVue service.
Not by default, unless you are using automatic sigin (a windows feature), that is never the case.
OOB JAVA will not do it (only the plugin has support for it, and the default NTLM implementation of JAVA), there is probably a mistake in you setup, autovue server will NOT send any auth or identity token
Simply because we need to handle HTTP 401
>> The applet and VueServlet is step 1 and once you are passed this and the person is authenticated it seems reasonable the DMS servlet would want to know who this person is to prevent passing sensitive data via the applet.
Yes, and what you are describing is a SSO solution, I would strongly recommend you look into an existing implementation
Basically, if you are web based, that means you can use a 3rd party tool (or attach the auth cookie to the applet html page)
If you are stand alone (DD), then you have very little option (none?). getting credential from the system requires specific code, and then you still need to propagate credential, without something like cookies, that is simply not feasible as you will defintively not get username/pwd.
>> If the JAAS built into AutoVue is used then does this get passed back to the DMS servlet via the authentication section for each request made to the servlet?
The sample JAAS authenticator is solely used for server side authentication, if you need something else, it needs to be coded
Basically, you are using LDAP and Kerberos, for SSO you will need to have an identity forwarding mechanism tied to your integration (a kerberos ticket), the authenticator on the client would need to implement one, the forward to the client then the client authenticator will need to query for username/password (or get a security context token from the process, can only be done on native code) and set the kerberos tickets (for identity fwding) as part of the query (a cookie), then the vuelink will need to process the ticket (validate the validity of the ticket with kerberos)
>> Passing all cookie data back is handy but these cookies are bound to the client they came from a lot of the time and will not work from the DMS servlet (as this is seen as a different client)
This is a implementation specific details, and only tied to how your implementation is done
Other (a vast majority of them) will rely on this mechanism, but then again, that means you have SSO